ASSISTANCE INFORMATION FOR EVOLVED NODE B (eNB) PARAMETER TUNING

ABSTRACT

Technology for a mobility management entity (MME) operable to provide core network assistance information is disclosed. The MME can determine the core network assistance information. The core network assistance information can include one or more of: an average connected state time for a user equipment (UE), an average idle state time for the UE, or a number of handover procedures between cells that occur for the UE in a selected time period. The MME can encode the core network assistance information for transmission from the MME to an eNodeB of the UE.

RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 14/582,373, filed Dec. 24, 2014 with a docket number of P63786,which claims priority to U.S. Provisional Patent Application No.61/993,877, filed Jan. 31, 2014 with a docket number of P63786Z, each ofwhich are hereby incorporated by reference in their entirety for allpurposes.

BACKGROUND

Machine type communication (MTC) is a communication that does nottypically require human intervention. The advent of machine typecommunication has brought about a new set of use cases for wirelessstandards and wireless communications systems. Wireless devices used forMTC or MTC applications typically have similar characteristics. Forexample, MTC devices typically have low mobility, low priority, and sendsmall amounts of mobile originated and/or mobile terminated data. Thedata is typically sent very infrequently, such as once a week, or once amonth. Alternatively, some types of MTC devices are configured to sendrelatively small amounts of MTC data more frequently. In order to sendthe data more frequently, an efficient means of connecting anddisconnecting the MTC device to a wireless network would be useful toreduce the impact that frequent connections and disconnections has onthe wireless network.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the disclosure will be apparent from thedetailed description which follows, taken in conjunction with theaccompanying drawings, which together illustrate, by way of example,features of the disclosure; and, wherein:

FIG. 1 illustrates an evolved Universal Mobile Telecommunications System(UMTS) Terrestrial Radio Access Network (e-UTRAN) in communication withan Evolved Packet Core (EPC) in accordance with an example;

FIG. 2 illustrates a timeline showing history release information inaccordance with an example;

FIG. 3 illustrates a flow chart depicting functionality of a mobilitymanagement entity (MME) configured to provide core network assistanceinformation in accordance with an example;

FIG. 4 illustrates a flow chart depicting functionality of an evolvedNode B (eNB) configured to receive core network assistance informationfor a user equipment (UE) in accordance with an example;

FIG. 5 depicts a flowchart of a method for providing core networkassistance information from a MME in an evolved packet core (EPC) to aserving eNB in accordance with an example; and

FIG. 6 illustrates a diagram of a wireless device (e.g., UE) inaccordance with an example.

Reference will now be made to the exemplary embodiments illustrated, andspecific language will be used herein to describe the same. It willnevertheless be understood that no limitation of the scope of theinvention is thereby intended.

DETAILED DESCRIPTION

Before the present invention is disclosed and described, it is to beunderstood that this invention is not limited to the particularstructures, process steps, or materials disclosed herein, but isextended to equivalents thereof as would be recognized by thoseordinarily skilled in the relevant arts. It should also be understoodthat terminology employed herein is used for the purpose of describingparticular examples only and is not intended to be limiting. The samereference numerals in different drawings represent the same element.Numbers provided in flow charts and processes are provided for clarityin illustrating steps and operations and do not necessarily indicate aparticular order or sequence.

Example Embodiments

An initial overview of technology embodiments is provided below and thenspecific technology embodiments are described in further detail later.This initial summary is intended to aid readers in understanding thetechnology more quickly but is not intended to identify key features oressential features of the technology nor is it intended to limit thescope of the claimed subject matter.

FIG. 1 is an example block diagram of an UE 102 in wirelesscommunication with an evolved packet system (EPS) comprising one or moreeNodeBs 104 that are in communication with an evolved packet core (EPC)in accordance with the 3GPP LTE Release 8, 9, 10, 11, 12 or 13. The EPCcan comprise a mobility management entity (MME). The MME can beconfigured to handle the control plane communication for each UE. Thecontrol plane signaling provides mobility and security for access forthe UE to the evolved Universal Mobile Telecommunications System (UMTS)Terrestrial Radio Access Network (E-UTRAN).

A Radio Resource Control (RRC) protocol layer is a sublayer that existsbetween the user equipment (UE) and the evolved Node B (eNB) in theE-UTRAN. The RRC protocol layer is part of an LTE air interface controlplane. The main services and functions provided by the RRC protocollayer include: the broadcast of system information related to thenon-access stratum (NAS) and the access stratum (AS); paging; theestablishment and release of an RRC connection between the UE and thee-UTRAN; the establishment, configuration, maintenance and release ofpoint to point radio bearers, and QOS measurement reporting. The MME isresponsible for the tracking and the paging of the UE in idle-mode. TheMME is the termination point of the Non-Access Stratum (NAS). Additionalfeatures are also provided by the RRC protocol layer.

The establishment of an RRC connection between the UE and the EPC allowscontrol information and data to be communicated between the UE and theMME using the control plane (comprising a signaling radio bearer betweenthe UE and the eNB and an S1-MME bearer between the eNB and the MME).When a UE is in an RRC connected mode, a relatively large amount ofpower is consumed at the UE. Accordingly, the RRC connected time at theUE is minimized in order to maximize the operating time of a UEoperating on a battery source. When it is not necessary or desired thata UE should maintain an RRC connected state with an EPS, then the UE canbe moved to an RRC idle state, which can minimize power usage until itis desired to reestablish the RRC connected state. The UE can move froman RRC connected state to an RRC idle state by when an RRC connectionrelease message is received from the eNB.

There is a careful balance between leaving a UE in an RRC connectedstate too long, which can result in excessive power drain at the UE, andtearing down an RRC connection too often, which can result in excessivesignaling overhead within a wireless network, such as the EPS, and powerusage at the UE to reestablish an RRC connection and associated radiobearers with the EPC.

The use of MTC devices can further exacerbate the challenges inoptimizing the timing of an RRC connection between a UE operating as anMTC device and a wireless network, such as the EPS. An MTC device can beconfigured to operate with very low power consumption. Thus, the timethe MTC device is in an RRC connected state is minimized to reduce powerconsumption. In addition, there can be thousands or tens of thousands ofMTC devices that may attempt to connect to the network in a relativelybrief amount of time.

For example, a UE operating as an MTC device may be connected to all ofthe power meters within a city. The meters can be configured tocommunicate power use at regular intervals, such as hourly, daily,weekly, or monthly. The connection of thousands or tens of thousands ofMTC devices to a wireless network can result in significant signalingoverhead at the E-UTRAN and the EPC. So it is important that each MTCdevice effectively communicates all necessary information with a minimumnumber of RRC connections and releases to reduce signaling overhead atthe wireless network. This example is not intended to be limiting. Awide variety of operating conditions and reporting conditions can existfor UEs operating as MTC devices.

In accordance with an embodiment of the present invention, assistanceinformation parameters can be communicated between an evolved packetsystem (EPS) and UEs to enhance the network's internal decisions andprovide power savings and performance enhancements at the UE.

The assistance information parameters can be used at the network toprovide load balancing control, resource allocation, and minimizesignaling overhead. The assistance information parameters can includeupdates to parameters associated with the RRC connection release timer,RRC states, and state transition related constants and counters.

The assistance information parameters can be gathered by a UE, a radioaccess network (RAN), or at the EPC (i.e. the MME or HSS). Theassistance information parameters can be stored at the eNB or the EPC.The assistance information parameters can be conveyed through differentmethods to benefit the UE and the network. For example, assistanceinformation can be conveyed upon a request or query from the network,upon handover of a UE to a different eNB, upon re-establishment of anRRC connection from an RRC idle state, or when a UE conveys informationdue to an internal decision at the UE. In addition, the assistanceinformation parameters can be used to adjust timing parameters ondiscontinuous reception (DRX) configurations for a UE. In times of loweractivity or no activity, the eNB can activate a DRX mode so that the UEcan power down its transceivers for some time defined by a set oftimers.

RRC Release Assistance Information

When an RRC connection release message is communicated, a UE can bemoved from an RRC connected mode to an RRC idle mode upon the expirationof a timer maintained at the eNB. The value, or parameter definition ofthis timer is typically operator or network specific. The value is notavailable in the 3GPP LTE Rel. 8, 9, 10, 11, 12 or 13 standard. Eachoperator uses a proprietary value for this timer and uses the value as ameans for differentiation with competing vendors. The timer is referredto as an “RRC inactivity timer” or an RRC connection release timer. TheRRC connection release timer is different from other timers defined inthe specification, such as the T320 timer.

The duration of the RRC connection release timer, which provides thetime that the UE takes before releasing the UE connection with the EPC,can have a huge impact on UE power consumption. If the time period istoo long, it can result in what is called a ‘tail effect’ during whichtime the UE is in connected mode but is not transmitting or receivingdata. However, if the time period is too short, it can result infrequent RRC state transitions, which can result in high signalingoverhead, as previously discussed.

In accordance with one embodiment of the present invention, a delta RRCrelease time can be configured. This delta RRC release time can be anassistance information parameter that can be used to enhance the networkprocedure for deciding when to release UE connections.

The delta RRC release time is a relative value of time (δ) that can beadded to a default instant that the eNB will release a UE's RRCconnection. The value of the delta RRC release time can be positive ornegative, thereby reducing or extending the default RRC release time.The delta RRC release time parameter can be generated by the eNB. TheeNB is the node that determines when to release the RRC connection withthe eNB in legacy systems. In one embodiment, the delta RRC release timevalue for each UE can be stored by the MME, along with a cellidentification (ID). However, the decision of releasing the UEconnection is not limited to the eNB. The decision of releasing the RRCconnection for the UE can also be taken by other nodes. For example, thedecision of releasing the RRC connection for a UE and the gathering ofassistance information used to determine the delta RRC release timevalue may be performed by the UE or nodes in the EPC, such as the MME.This information can be used to determine an improved instance torelease the connection that will minimize UE power usage and networktraffic.

The delta RRC release time information can allow the eNB to define itsown absolute RRC release time. In addition, the eNB can be configured todefine its own mechanism to determine how and when to release a UE's RRCconnection in a future instance. Intelligent eNBs can also be configuredto consider additional factors such as the handover (HO) rate for a UE,a UE traffic pattern, or other internal algorithms at the eNB todetermine when to release the RRC connection.

For example, an eNB may define its internal constant RRC release time(t_(D)) to 5 seconds. A handover may be triggered for a UE that hasalready been without data activity for 3 seconds. At that point, the eNBcan be configured to release the UE. Therefore, the delta RRC releasetime can be stored as being equal to negative two seconds (δ_(A)=−2) bythe MME, as illustrated in FIG. 2. The next time that the UE enters anRRC connected state, the eNB can also include the delta RRC release timevalue as a factor that can be used to assist in determining a timeperiod in which to release the RRC connection to minimize networksignaling and save UE power consumption and network resources.

Similarly, there can be cases when the eNB determines not to release theUE and to keep it connected for a longer period, in which case therelative value of the delta RRC release time is positive, illustrated asδ_(B) in FIG. 2.

In the case of an inter-eNB handover from a source eNB to a target eNB,the delta RRC release time can be communicated from the source eNB tothe target eNB. The target eNB can then be configured to use thisinformation to minimize network signaling and UE power consumption. Inaddition to communicating a delta RRC release time, additionalinformation can also be communicated. For example, assistanceinformation relating to a case in which a UE is kept in a connected modewithout transiting to an idle mode may be communicated to the targeteNB.

Assistance information such as the delta RRC release time can be used tounderstand the traffic activity based on the time that a UE spends inRRC connected mode and RRC idle mode. The specific details can be usedby the network to reduce signaling overhead incurred due to frequent RRCstate transitions.

In one example embodiment, information can be collected by one or moreUEs and communicated by each UE to the EPC. A node in the EPC, such asthe MME, can use the information to provide assistance information tothe eNB to minimize the UE state transitions and achieve optimum networkbehavior. In another embodiment, the information can be collected by theMME itself.

For instance, a UE can convey, upon establishing an RRC connection,certain mobility related information. The mobility related informationcan include a list of cell ID and the time spent by the UE in each cell.The cell history can be kept for a predetermined amount of time, such as60, 120, 240, or 480 seconds. The mobility information can becommunicated to the EPC in other time instants. For instance, the eNB orMME may request the information.

The mobility related information, such as RRC state information, can becollected by the UEs and associated with selected cells for certainperiods of time. In one example, the information can be collected asillustrated in the proceeding paragraphs.

The time spent by a UE in each state per cell can be represented as:{(cell_1, time_idle_1, time_connected_1), (cell_2, time_idle_2,time_connected_2), . . . , (cell_n, time_idle_n, time_connected_n)},where cell_x refers to cell_ID_x and/or cell_type_x; time_idle_x refersto the time that the UE was in an RRC idle state in Cell_x; andtime_connected_x refers to the time that the UE is in an RRC connectedstate in Cell_x.

The time spent by a UE in each state without extrapolation can berepresented as {(cell_1, time_RRCstate_1, RRCstate_1), (cell_2,time_RRCstate_2, RRCstate_2), . . . , (cell_n, time_RRCstate_n,RRCstate_n)} in which RRCstate_n represents the RRC state the UE is in.For example, RRC idle can be designated as 0 and RRC connected can bedesignated as 1.

The number of RRC state transitions per cell, with the time spent ineach cell or the RRC state transition rate per cell, can be representedas: {(cell_1, time_cell_1, RRCstate_count_1), (cell_2, time_cell_2,RRCstate_count_2), . . . , (cell_n, time_cell_n, RRCstate_count_n)} or{(cell_1, RRCstate_ratio_1), (cell_2, RRCstate_ratio_2), . . . ,(cell_n, RRCstate_ratio_n)}. Time_cell is the time spent in a givencell/eNB. RRCstate_count is the number of RRC_idle to RRC_connectedstate transitions performed by a UE while in the given cell.RRCstate_ratio is the ratio of time spent in RRC_idle to time spent inRRC_connected state, or vice versa.

In one embodiment, only the average and standard deviation (or variance)for the time spent by the UE in a cell is included. In this embodiment,the time spent by the UE in an RRC idle mode and the time spent by theUE in an RRC connected mode per cell can be represented as the number ofRRC state transitions per cell over a certain period of time. Forinstance, the information collected can include: {(cell_1,average_time_idle_1, average_time_connected_1, std_time_idle_1,std_time_connected_1), etc., where average_time_idle_n is the averageamount of time that the UE is in an RRC idle time in cell_n;std_time_idle_n is the standard deviation of the time the UE is in idlein cell _n; and average_time_connected_n is the average time the UE isin an RRC connected state in cell_n.

In one embodiment, the assistance information can include a history ofRRC state transitions for a UE based on a weighted method. The node,such as the eNB or MME, that gathers raw information of RRC statetransitions and the corresponding durations, can perform some form ofweighting before sharing the information as assistance information. Theweighting of the information can be done in different ways in additionto the exemplary methods. For example, weighting can be applieddifferently to the time spent that the UE spends in an RRC connectedstate and an RRC idle state over a window of time. Time base weightingcan also be applied. The window can be either sliding or fixed.

The assistance information can also be decoupled from the UE cellhistory information (referring to the cell ID). Upon the request of thenetwork, the UE can send the following information as different options:the assistance information only contains the time of stay and RRC stateof each transition; or the assistance information can be the average anddeviation (or variance) of the time that the UE has stayed in each cellover a window of time.

Conveying Assistance Information

In one embodiment, the UE can use an existing UE assistance informationcontainer to send the assistance information to convey the assistanceinformation to the network, such as the MME in the EPC. In addition, anew message can be used to convey the assistance information to thenetwork. In another example, the UE can communicate the UE assistanceinformation to the eNB. The eNB may use the eNB configuration update orS1 setup request or any other appropriate S1 message to convey theinformation to the MME for storage.

In another embodiment, the UE can communicate UE assistance informationwhen moving from an RRC idle state to an RRC connected state. Theassistance information can also be communicated to the network or atarget eNB at the event of a handover. For example, the information canbe sent via an X2 connection from a serving eNB to a target eNB when theUE is handed over to another cell. The network can update theinformation and add the time of stay of the current cell information toa list, as previously discussed. If only average and standard deviation(or variance) information is sent to the network, the network, such asan element in the EPC, EPS, or an external element that is incommunication with the EPC via the P-GW, the network can eitherre-calculate the average and standard deviation (or variance) based onthe time the UE has stayed in the cell, or request the UE to update theinformation and send it to the network.

In one embodiment, if the information is decoupled with the UE historyinformation that is sent to the eNB upon the UE's transition from RRCidle to RRRC connected, a new signaling can be added in the RRC messagefor the network to request such information.

In accordance with one example, functionality 300 of a mobilitymanagement entity (MME) in an evolved packet core (EPC) that isconfigured to provide core network assistance information is disclosed,as shown in the flow chart of FIG. 3. The functionality can beimplemented as a method or the functionality can be executed asinstructions on a machine, where the instructions are included on atleast one computer readable medium or one non-transitory machinereadable storage medium. The MME can include one or more processorsconfigured to: determine an average radio resource control (RRC)connected state time for a user equipment (UE), as shown in block 310;determine an average RRC idle state time for the UE, as shown in block320; identify an amount of time the UE spends in cells in the EPC todetermine a number of handover procedures between cells in a selectedtime period, as shown in block 330; and communicate the core networkassistance information comprising the RRC connected state time, the RRCidle state time, and the number of handover procedures in the selectedtime period to a serving evolved Node B (eNB) of the UE to enable theserving eNB to reduce UE state transitions for the UE, as shown in block340.

In another example, the core network assistance information can becommunicated to the serving eNB via an S1 connection with the MME. Theone or more processors can be further configured to communicate the corenetwork assistance information to a target eNB at a handover of the UEto enable the target eNB to reduce UE state transitions for the UE. Forexample, the target eNB can reduce the number of times the UEtransitions between an RRC connected state and an RRC idle state.

In another example, the one or more processors can be further configuredto communicate, from the MME to the serving eNB, a time that the UE isin the RRC connected state. In addition, the one or more processors canbe further configured to communicate, from the MME to the serving eNB, atime period that the UE is in the RRC idle state. The one or moreprocessors can be further configured to communicate, from the MME to theserving eNB, an indication that the core network assistance informationis based on statistical information collected at the MME.

Another example provides functionality 400 of an evolved Node B (eNB)configured to receive core network assistance information for a UE, asshown in the flow chart of FIG. 4. The functionality can be implementedas a method or the functionality can be executed as instructions on amachine, where the instructions are included on at least one computerreadable medium or one non-transitory machine readable storage medium.The eNB can have one or more processors that are configured to receive,from a mobility management entity (MME) in an evolved packet system(EPS) of the eNB, the core network assistance information, as shown inblock 410. The core network assistance information can include anaverage time that the UE is in a connected state with the MME, as shownin block 420; an average time that the UE is in an idle state with theMME, as shown in block 430; and a number of handover procedures betweencells that occur for the UE in a selected time period, as shown in block440. The one or more processors can be further configured to adjustselected parameters for the UE based on the core network assistanceinformation to reduce state transitions of the UE and network signalingoverhead, as shown in block 450.

In another example, the one or more processors of the UE can be furtherconfigured to receive the core network assistance information for a UEfrom the MME. The one or more processors of the UE can also beconfigured to communicate, via an X2 connection with a target eNB, thecore network assistance information from the eNB to the target eNB at ahandover of the UE to enable the target eNB to reduce UE statetransitions for the UE.

The one or more processors can be further configured to receive, fromthe MME, an time interval between handover procedures for the UE. Inaddition, the one or more processors can be further configured toreceive, from the MME a time period that the UE is in the connectedstate, wherein the connected state is a radio resource control (RRC)connected state; and a time period that the UE is in the idle state,wherein the idle state is a radio resource control (RRC) idle state.Also, the one or more processors of the eNB can be configured toreceive, from the MME, an indication that the core network assistanceinformation is based on statistical information collected at the MME.

Another example provides a non-transitory machine readable storagemedium having instructions embodied thereon, the instructions which whenexecuted by one or more processors perform the following operations toprovide core network assistance information from a mobility managemententity (MME) in an evolved packet core (EPC) to a serving evolved Node B(eNB), as shown in the flow chart of FIG. 5. The operations comprise:determine an average time that a user equipment (UE) is in a connectedstate with the MME, as shown in block 510; determine an average timethat the UE is in an idle state with the MME, as shown in block 520;identify an amount of time the UE spends in cells in the EPC todetermine a number of handover procedures between cells in a selectedtime period, as shown in block 530; and communicate the core networkassistance information comprising the connected state time, the idlestate time, and the number of handover procedures in the selected timeperiod to the serving (eNB) of the UE to enable the serving eNB toreduce UE state transitions for the UE, as shown in block 540.

Further instructions for the at least one non-transitory machinereadable storage medium comprise communicating the core networkassistance information to the serving eNB via an S1 connection with theMME; and communicating the core network assistance information to atarget eNB at a handover of the UE to enable the target eNB to reduce UEstate transitions for the UE. The state transitions for the UE caninclude transitions between an RRC connected state and an RRC idlestate, as previously discussed. The instructions can be executed by theone or more processors.

Further instructions for the at least one non-transitory machinereadable storage medium comprise: communicating, from the MME to theserving eNB, a time interval between handover procedures for the UE;communicating, from the MME to the serving eNB, a time period that theUE will be in the connected state, wherein the connected state is aradio resource control (RRC) connected state; and communicate, from theMME to the serving eNB, a time period that the UE is in the idle state,wherein the idle state is a radio resource control (RRC) idle state. Theinstructions can further comprise communicating, from the MME to theserving eNB, an indication that the core network assistance informationis based on statistical information collected at the MME. Theinstructions can be executed by the one or more processors.

FIG. 6 provides an example illustration of the wireless device, such asan user equipment (UE), a mobile station (MS), a mobile wireless device,a mobile communication device, a tablet, a handset, or other type ofwireless device. The wireless device can include one or more antennasconfigured to communicate with a node, macro node, low power node (LPN),or, transmission station, such as a base station (BS), an evolved Node B(eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radioequipment (RRE), a relay station (RS), a radio equipment (RE), or othertype of wireless wide area network (WWAN) access point. The wirelessdevice can be configured to communicate using at least one wirelesscommunication standard including 3GPP LTE, WiMAX, High Speed PacketAccess (HSPA), Bluetooth, and WiFi. The wireless device can communicateusing separate antennas for each wireless communication standard orshared antennas for multiple wireless communication standards. Thewireless device can communicate in a wireless local area network (WLAN),a wireless personal area network (WPAN), and/or a WWAN.

FIG. 6 also provides an illustration of a microphone and one or morespeakers that can be used for audio input and output from the wirelessdevice. The display screen can be a liquid crystal display (LCD) screen,or other type of display screen such as an organic light emitting diode(OLED) display. The display screen can be configured as a touch screen.The touch screen can use capacitive, resistive, or another type of touchscreen technology. An application processor and a graphics processor canbe coupled to internal memory to provide processing and displaycapabilities. A non-volatile memory port can also be used to providedata input/output options to a user. The non-volatile memory port canalso be used to expand the memory capabilities of the wireless device. Akeyboard can be integrated with the wireless device or wirelesslyconnected to the wireless device to provide additional user input. Avirtual keyboard can also be provided using the touch screen.

Various techniques, or certain aspects or portions thereof, can take theform of program code (i.e., instructions) embodied in tangible media,such as floppy diskettes, CD-ROMs, hard drives, non-transitory computerreadable storage medium, or any other machine-readable storage mediumwherein, when the program code is loaded into and executed by a machine,such as a computer, the machine becomes an apparatus for practicing thevarious techniques. Circuitry can include hardware, firmware, programcode, executable code, computer instructions, and/or software. Anon-transitory computer readable storage medium can be a computerreadable storage medium that does not include signal. In the case ofprogram code execution on programmable computers, the computing devicecan include a processor, a storage medium readable by the processor(including volatile and non-volatile memory and/or storage elements), atleast one input device, and at least one output device. The volatile andnon-volatile memory and/or storage elements can be a RAM, EPROM, flashdrive, optical drive, magnetic hard drive, solid state drive, or othermedium for storing electronic data. The node and wireless device canalso include a transceiver module, a counter module, a processingmodule, and/or a clock module or timer module. One or more programs thatcan implement or utilize the various techniques described herein can usean application programming interface (API), reusable controls, and thelike. Such programs can be implemented in a high level procedural orobject oriented programming language to communicate with a computersystem. However, the program(s) can be implemented in assembly ormachine language, if desired. In any case, the language can be acompiled or interpreted language, and combined with hardwareimplementations.

It should be understood that many of the functional units described inthis specification have been labeled as modules, in order to moreparticularly emphasize their implementation independence. For example, amodule can be implemented as a hardware circuit comprising custom VLSIcircuits or gate arrays, off-the-shelf semiconductors such as logicchips, transistors, or other discrete components. A module can also beimplemented in programmable hardware devices such as field programmablegate arrays, programmable array logic, programmable logic devices or thelike.

In one example, multiple hardware circuits can be used to implement thefunctional units described in this specification. For example, a firsthardware circuit can be used to perform processing operations and asecond hardware circuit (e.g., a transceiver) can be used to communicatewith other entities. The first hardware circuit and the second hardwarecircuit can be integrated into a single hardware circuit, oralternatively, the first hardware circuit and the second hardwarecircuit can be separate hardware circuits.

Modules can also be implemented in software for execution by varioustypes of processors. An identified module of executable code can, forinstance, comprise one or more physical or logical blocks of computerinstructions, which can, for instance, be organized as an object,procedure, or function. Nevertheless, the executables of an identifiedmodule need not be physically located together, but can comprisedisparate instructions stored in different locations which, when joinedlogically together, comprise the module and achieve the stated purposefor the module.

Indeed, a module of executable code can be a single instruction, or manyinstructions, and can even be distributed over several different codesegments, among different programs, and across several memory devices.Similarly, operational data can be identified and illustrated hereinwithin modules, and can be embodied in any suitable form and organizedwithin any suitable type of data structure. The operational data can becollected as a single data set, or can be distributed over differentlocations including over different storage devices, and can exist, atleast partially, merely as electronic signals on a system or network.The modules can be passive or active, including agents operable toperform desired functions.

Reference throughout this specification to “an example” means that aparticular feature, structure, or characteristic described in connectionwith the example is included in at least one embodiment of the presentinvention. Thus, appearances of the phrases “in an example” in variousplaces throughout this specification are not necessarily all referringto the same embodiment.

As used herein, a plurality of items, structural elements, compositionalelements, and/or materials can be presented in a common list forconvenience. However, these lists should be construed as though eachmember of the list is individually identified as a separate and uniquemember. Thus, no individual member of such list should be construed as ade facto equivalent of any other member of the same list solely based ontheir presentation in a common group without indications to thecontrary. In addition, various embodiments and example of the presentinvention can be referred to herein along with alternatives for thevarious components thereof. It is understood that such embodiments,examples, and alternatives are not to be construed as defactoequivalents of one another, but are to be considered as separate andautonomous representations of the present invention.

Furthermore, the described features, structures, or characteristics canbe combined in any suitable manner in one or more embodiments. In thefollowing description, numerous specific details are provided, such asexamples of layouts, distances, network examples, etc., to provide athorough understanding of embodiments of the invention. One skilled inthe relevant art will recognize, however, that the invention can bepracticed without one or more of the specific details, or with othermethods, components, layouts, etc. In other instances, well-knownstructures, materials, or operations are not shown or described indetail to avoid obscuring aspects of the invention.

While the forgoing examples are illustrative of the principles of thepresent invention in one or more particular applications, it will beapparent to those of ordinary skill in the art that numerousmodifications in form, usage and details of implementation can be madewithout the exercise of inventive faculty, and without departing fromthe principles and concepts of the invention. Accordingly, it is notintended that the invention be limited, except as by the claims setforth below.

What is claimed is:
 1. An apparatus of a mobility management entity(MME) operable to provide core network assistance information, theapparatus comprising: one or more processors configured to: determine,at the MME, core network assistance information, wherein the corenetwork assistance information includes one or more of: an averageconnected state time for a user equipment (UE), an average idle statetime for the UE, or a number of handover procedures between cells thatoccur for the UE in a selected time period; and encode the core networkassistance information for transmission from the MME to an eNodeB of theUE; and memory configured to store the core network assistanceinformation.
 2. The apparatus of claim 1, wherein the one or moreprocessors are further configured to: determine the average connectedstate time for the UE; determine the average idle state time for the UE;identify an amount of time the UE spends in cells associated with anEvolved Packet Core (EPC) for the MME to determine the number ofhandover procedures between cells in the selected time period; andinclude one or more of the average connected state time, the averageidle state time, or the number of handover procedures in the selectedtime period in the core network assistance information.
 3. The apparatusof claim 1, wherein the one or more processors are further configured toencode the core network assistance information for transmission to theeNodeB via an S1 connection with the MME.
 4. The apparatus of claim 1,wherein the one or more processors are further configured to encode thecore network assistance information for transmission to a target eNodeBat a handover of the UE to enable the target eNodeB to reduce UE statetransitions for the UE.
 5. The apparatus of claim 1, further comprisinga transceiver configured to communicate, from the MME to the eNodeB, atime interval between handover procedures for the UE.
 6. The apparatusof claim 1, further comprising a transceiver configured to communicate,from the MME to the eNodeB, a time period that the UE is in theconnected state.
 7. The apparatus of claim 1, further comprising atransceiver configured to communicate, from the MME to the eNodeB, atime period the UE is in the idle state.
 8. The apparatus of claim 1,further comprising a transceiver configured to communicate, from the MMEto the eNodeB, an indication that the core network assistanceinformation is based on statistical information collected at the MME. 9.An apparatus of an eNodeB operable to receive core network assistanceinformation for a user equipment (UE), the apparatus comprising: one ormore processors configured to: decode the core network assistanceinformation received from an mobility management entity (MME) in anevolved packet system (EPS) of the eNodeB; and adjust selectedparameters for the UE based on the core network assistance informationto reduce state transitions of the UE and network signaling overhead;and memory configured to store the core network assistance informationreceived from the MME.
 10. The apparatus of claim 9, wherein the corenetwork assistance information includes: an average time that the UE isin a connected state with the MME, an average time that the UE is in anidle state with the MME, and a number of handover procedures betweencells that occur for the UE in a selected time period.
 11. The apparatusof claim 9, having one or more processors further configured to encodethe core network assistance information for transmission from the eNodeBto a target eNodeB via an X2 connection at a handover of the UE toenable the target eNodeB to reduce UE state transitions for the UE. 12.The apparatus of claim 9, further comprising a transceiver configured toreceive, from the MME, a time interval between handover procedures forthe UE.
 13. The apparatus of claim 9, further comprising a transceiverconfigured to receive, from the MME, a time period the UE is in theconnected state, wherein the connected state is a radio resource control(RRC) connected state.
 14. The apparatus of claim 9, further comprisinga transceiver configured to receive, from the MME, a time period the UEis in the idle state, wherein the idle state is a radio resource control(RRC) idle state.
 15. The apparatus of claim 9, further comprising atransceiver configured to receive, from the MME, an indication that thecore network assistance information is based on statistical informationcollected at the MME.
 16. At least one non-transitory machine readablestorage medium comprising instructions embodied thereon for providingcore network assistance information from a mobility management entity(MME), the instructions when executed by one or more processors causethe MME to perform the following: determining, at the MME, the corenetwork assistance information, wherein the core network assistanceinformation includes one or more of: an average connected state time fora user equipment (UE), an average idle state time for the UE, or anumber of handover procedures between cells associated with an EvolvedPacket Core (EPC) for the MME in a selected time period; and encodingthe core network assistance information for transmission from the MME toan eNodeB of the UE; and
 17. The at least one non-transitory machinereadable storage medium of claim 16, further comprising instructionswhich when executed by the one or more processors cause the MME toperform the following: determining the average connected state time forthe UE; determining the average idle state time for the UE; identifyingan amount of time the UE spends in cells associated with the EPC for theMME to determine the number of handover procedures between cells in theselected time period; and including one or more of the average connectedstate time, the average idle state time, or the number of handoverprocedures in the selected time period in the core network assistanceinformation.
 18. The at least one non-transitory machine readablestorage medium of claim 16, further comprising instructions which whenexecuted by the one or more processors cause the MME to perform thefollowing: encoding the core network assistance information fortransmission to the eNodeB via an S1 connection with the MME.
 19. The atleast one non-transitory machine readable storage medium of claim 16,further comprising instructions which when executed by the one or moreprocessors cause the MME to perform the following: encoding the corenetwork assistance information for transmission to a target eNodeB at ahandover of the UE to enable the target eNodeB to reduce UE statetransitions for the UE.
 20. At least one non-transitory machine readablestorage medium comprising instructions embodied thereon for receivingcore network assistance information for a user equipment (UE), theinstructions when executed by one or more processors cause an eNodeB toperform the following: decoding, at the eNodeB, the core networkassistance information received from an mobility management entity (MME)in an evolved packet system (EPS) of the eNodeB; and adjusting, at theeNodeB, selected parameters for the UE based on the core networkassistance information to reduce state transitions of the UE and networksignaling overhead.
 21. The at least one non-transitory machine readablestorage medium of claim 20, wherein the core network assistanceinformation includes: an average time that the UE is in a connectedstate with the MME, an average time that the UE is in an idle state withthe MME, and a number of handover procedures between cells that occurfor the UE in a selected time period; and
 22. The at least onenon-transitory machine readable storage medium of claim 20, furthercomprising instructions which when executed by the one or moreprocessors cause the eNodeB to perform the following: encoding the corenetwork assistance information for transmission from the eNodeB to atarget eNodeB via an X2 connection at a handover of the UE to enable thetarget eNodeB to reduce UE state transitions for the UE.